Communication Infrastructures and Protocols for Mobile Agent

Mobile agent is an emerging technology that will greatly extend the existing distributed computing mechanisms on computer network. It is evolutionarily being developed on the basis of existing transport and network level protocols within the OSI network model, to achieve autonomy and mobility of programs on application level. Researchers are working on several aspects including conceptual modeling, communication infrastructure/protocol, communication languages, distributed processing control, and security, to promote the commercial usability of mobile agent. In this paper I investigate so far available proposals on mobile agent communication infrastructure and protocol and the concern of communication reliability, after a brief review of the existing network communication framework, especially the dominating internetwork protocol suite TCP/IP and HTTP, which is the ground of the current research of mobile agent, and an introduction to mobile agent. 1. Brief Review of Computer Communications The emergence of computer significantly extends human’s computing ability, and the creeping of communication technology onto computer significantly extends computer’s computing ability. The combination of computer and communication generates the whole range of computer network technologies which change the traditional standalone computation on individual computer into distributed computation on connected cooperative computers. A complicated task can be performed by cooperation of several computers each of which contributes its strength and expertise so that it is more efficient than fulfilling the task by a standalone computer. Computer cooperation means information exchange between computers, more precisely between programs residing at different computers on the connecting network. To be practical, there must be some protocols that are recognized by all cooperating parties, analogous to the need of a common language for a cooperating group which members are from different countries. The most theoretically complete computer communication protocol framework is the OSI model, which breaks the complexity of communication task down to seven subtasks that are presented as a column of seven layers in top-down fashion: application, presentation, session, transport, network, data link, and physical layer. Each layer is well defined in terms of the functions to be performed and boundaries against adjacent layers, so that concrete protocols can be implemented for individual layers independently (Stallings, chapter 2). As the computer networks expand rapidly and raise the demand of networking from computer interconnection up to network interconnection, another similar but more practical protocol architecture other than OSI, namely TCP/IP protocol suite, dominates the market place because of its simplicity for implementation and strong usability over any network access protocols on lower layers. The latter characteristic is achieved by Internet Protocol (IP) that acts as common rules for communications on network layer, forming an internetwork sub-layer, between heterogeneous networks and computer systems which are usually globally distributed and highly diverse (Stallings, chapter 15). Heterogeneity is one of the hardest problems in distributed computing and it is in some degree solved by TCP/IP on network level. That’s why bunch of applications based on internetworking, such as remote login, electronic mail, file transfer and the most prominent WWW, flourish and boost the formation and popularity of Internet. Another key feature of TCP/IP protocol architecture to support variety of distributed computing is Transmission Control Protocol (TCP), which works above the IP and provides transport service to upper layer users. TCP is a connection-oriented protocol. It establishes and maintain end-to-end connections for users and deals with congestion control, error detection and crash recovery to ensure reliable communication and delivery upon those connections. In such a way the upper layer application programs do not have to worry about the complexity of underlying network communication and instead focus on what to talk with the destination programs efficiently (Stallings, chapter 17). With the strong support of whole range of communication hardware and above mentioned underlying sophisticated protocols, any programs in different globally located computing devices can talk to each other in whatever way they want on application layer, as long as a paths exist across some network or interconnected networks between the talking parties. Sophisticated distributed applications can be developed since distributed systems now can cooperate in any way you can think of and program. The different ways in which different programs talk with each other also appeal to protocols on application layer. Simple Mail Transfer Protocol (SMTP) and Hyper Text Transfer Protocol (HTTP) are two heavily used protocol examples. SMTP is a distributed application protocol for transferring mails between SMTP servers over TCP connections. The SMTP sender and receiver communicate in a way of command/reply which formats are defined in RFC 821 (Postel). The initiative of SMTP operations is with the SMTP sender who establishes the TCP connection and sends a series of commands and mail messages each of which generate exactly one reply from the SMTP receiver as acknowledgement. Even though SMTP is not concerned with the format of the mail messages, SMTP server programs usually adopt format defined in RFC 822 for text messages (Crocker), and its extension MIME format for multiple objects and non-textual content such as audio, video, image and general binary data (Freed). HTTP is the foundation protocol of the most popular application on Internet: world wide web. It works in a way of client/server as well as transaction fashion. Each HTTP transaction between client and server programs consists of exactly one pair of HTTP messages, i.e. a request message from client to server and a response message backwards. Transactions are completely independent on each other and there is no way to directly exchange information between transactions by themselves. This stateless feature is well suited for the highly distributed clients and servers in WWW applications. Typical implementation for this “stateless” feature is to create a new TCP connection between client and server for a transaction, and terminate that connection when the transaction finishes (Stalling, chapter 19). Not like the simple format of commands and replies in SMTP, HTTP request and response message units are far more sophisticated and can contain abundant information. Each request message consists of a method name, a URL and optionally a MIME-like message containing header section and entity body. Each response message consists of an optional status line and a MIME-like message, again containing header and body. Even though both headers follow the same generic format as RFC 822, there are a large number of header fields and parameters defined in HTTP. So both the request and response can be used to transfer any type of data and, the most attractively, a client can request information from any server by defining the URL of the information in the request, and a server can respond to all clients globally distributed and sending requests (Fielding). Besides WWW in which the browsers request information and get response from web servers on behalf of their users, HTTP can be used for many tasks such as naming servers and distributed object management systems, as well as connecting users to other protocols like SMTP and FTP by building up HTTP gateways. A whole range of request methods are defined and more can be extended in the future so that HTTP can adapt many current and coming applications on Internet. 2. Introduction of Mobile Agent Although the current application protocols and the corresponding application implementations enable distributed computing on network and internetwork in any complexity, they are far from performing distributed computing efficiently. For a complicated task, cooperating end systems may have to communicate back and forth many times, reasonable response speed is expected from the communication parties, and when the target end systems are busy, the initiative end systems either keep the idle network connection and wait, or fail the whole task which may be close to be done. Moreover, the distribution of subtasks is based on the expertise of the end systems so that the computation burden cannot be evenly distributed and the host playing key role in computations could be overwhelmed by workload. Another problem is heterogeneity. Even though it is solved in some degree on network layer, it still causes inefficiency on application level when an application on a host try to cooperate with highly heterogeneous applications and systems in the globally distributed environment. The inflexibility and inefficiency of stationary programs in the rapidly expanding Internet applications, together with the rise of objected-oriented concept and platform-independent Java technology, naturally inspired movement of programs among hosts within a distributed environment. That is the emerging mobile agent technology. A mobile agent is an active program that can roam a network by transporting itself from host to host, and carry out autonomous operations to fulfill a user assigned task (Piszcz, 1-3). From OOP point of view, a mobile agent is an object that contains its state and some result of its task, and most importantly its intelligent behavior including self-governing and self-dispatching. Ideally speaking, mobile agent will at least have the following characteristics and abilities (White): (a) Mobility: transport itself from host to host within a network then resume execution (b) Autonomy: settle, execute and move independently without supervision (c) Loyalty: performance computation on behalf of the user who creates it (d) Intelligence: learn from the information it gets and make decisions, e.g. where to move next (e) Recursion: create child agents for subtasks if necessary This general idea of mobile agent has maximum flexibility and adaptability and is applicable to the whole variety of network distributed applications, but is hard to completely implement based on the current technologies. Applications are still on experimental level and concentrate on some specific but most valuable areas, including web databases, cooperative environments, information gathering systems and E-commerce systems (Samaras). For example, if we apply the general idea of mobile agent to the most popular web application, a rough pattern could be like this: the stationary user agent such as web browser accepts user’s request and corresponding requirements (parameters) as a whole task, create one or more mobile agents and assign the task or part of the task to them together with the user’s ID. A mobile agent decides the destination server based on its task, then creates or asks the host to create a TCP connection with that server, halt its execution and dispatch itself to that server. On each visited server a mobile agent, the mobile agent negotiates with the server on behalf of its user for residency and required resources, resides and resumes execution, executes part or all of its task, retrieve local information or makes deals, and makes decision for next step based on the outcome for its task. Next step may be dispatching itself back to owner system for result delivery, dispatching itself to another server for further information, create child mobile agents to perform some subtasks. This pattern is depicted in the following graph: The benefits to apply mobile agent to web applications over traditional client/server architecture are obvious. Because the mobile agent can negotiate for satisfactory resources, the computation burden can be flexibly distributed among the client system and all service providers that can host mobile agent (Samaras). The mobile agent requests and gets service locally on hosts of service providers instead of on the client or web server. No matter how complex the task is, the client just need to send out the agent and wait for its return, rather than communicating with server C client agent server B